Google Cloud でクラウドHPCを体験してみよう
Googleが考えるクラウドHPCの在り方を知りたいという興味から、Google CloudでクラウドHPCに入門してみました。Google Cloudでクラスター環境を構築し、テストジョブを投げて結果を確認するといったチュートリアルにもお使い頂ける内容になったかと思います。
まず、クラスター環境の構築方法について調べました。Marketplaceから利用できるクラスターのデプロイ環境構築するCloud Deployment Managerが提供されていました。こちらを利用するとGoogle Cloudに不慣れな方でも簡単にクラスターデプロイが可能なので、以下のリンクをベースに進めていきます。
この記事で学べること
ジョブスケジューラーはSlurmを利用します。
- HPCクラスター環境の構築
- テストジョブを投入し、コンピューノードの動作確認
- HPCクラスター環境の削除
Marketplace
こちらのLinkよりSchedmd-Slurm-GCPを有効化します。
クラスター環境を構築するプロジェクトでは有効にになっていないAPIがありました。この場で必要なAPIを有効化してくれる親切設計でした。
有効化すると、Cloud Deployment Mangerの画面に遷移します。
クラスター環境の設定
早速、クラスターの設定が面に切り替わりました。
クラスターの名前と、構築するリージョンを指定します。東京（asia-northeast1-a）に作成します。
ネットワーク設定はデフォルトのものしかないためデフォルトを指定します。
コントローラーのVMインスタンスの設定です。CPUはAMDを使いたいためN2Dシリーズを選択します。コントローラーはジョブスケジュールが主な役割でしょうから、マシンタイプは安価なタイプを選択しました。
SlurmのPartitionを初期設定できます、素敵です。Partition毎に特色のあるコンピューノードの設定をしておくことで、ジョブの特性に応じたコンピューノードへ投げ分けが簡単できます。その他、Google Cloudの余剰リソースを安価にコンピュートリソースとして利用するPreemptible Instancesを有効にします。AWSでいうEC2のスポットインスタンスのことですね。
コンピュートノードの選択です。うーん、ロマンありますねぇ。単体のマシンタイプで224vCPUあるのはアツい。
オプションでPartitionを追加設定できます。ロマンのない自重したスペックでコンピュートノード設定を追加しておきます。
さらにPartition追加できます。今回は2つのPartitonを作成したのでテストには充分です。
クラスター環境をデプロイします。
クラスター構築待ちです。
2-3分で完成しました。早すぎて驚きました。
Compute EngineからVMインスタンスを確認します。Controllerと、Login0の2インスタンスを確認できます。
SSH TO SLURM LOGIN NODEをクリックすると別ウィンドウでコントロールノードへSSH接続した画面が起動しました。
ホスト名とプライベートIPアドレスからLogin0のVMインスタンスへ接続されていることが確認できます。
$ hostname
blog-sample-cluster-login0
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc mq state UP group default qlen 1000
link/ether 42:01:0a:92:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.146.0.3/32 brd 10.146.0.3 scope global noprefixroute dynamic eth0
valid_lft 85717sec preferred_lft 85717sec
inet6 fe80::4ee3:effd:a8dd:a743/64 scope link noprefixroute
valid_lft forever preferred_lft forever
コンピュートノード復数指定でジョブ登録
初期設定したPartitionが2個（p1, p2）確認できます。
$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST p1* up infinite 10 idle~ blog-sample-cluster-compute-0-[0-9] p2 up infinite 10 idle~ blog-sample-cluster-compute-1-[0-9]
テストジョブ投げるためのシェルスクリプトを作成します。実行したノードのホスト名を返すだけの内容です。
cat > example.sh << EOF #!/bin/bash srun hostname EOF $ ls example.sh
テストジョブを登録しました。自重したコンピュートノードが起動するPartition2（p2）を使ってテストジョブを処理してもらいます。4プロセス指定で起動させます、vCPU数でカウントされるのか定かではないのですが、2vCPUのマシンタイプなので2台以上のコンピュートノードが起動する予定です。
$ sbatch -p p2 -n 4 example.sh Submitted batch job 2
NODESが4となっているため4プロセス指定で4台必要となっていました。
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2 p2 example. ohmura_y CF 1:06 4 blog-sample-cluster-compute-1-[0-3]
コンピュートノード3台はすぐに起動したのですが最後の1台が起動してきません。1台だけというのはなにか問題がありそうです。
CPU上限制限解除
VMインスタンスのクォータがあやしいです。 こちらのLinkからクォータを確認します。
N2DのCPU数に警告マークが表示されています。詳細を確認します。
デフォルトの上限は8CPUでした。必要数分の上限緩和すればよいだけですね。
上限を512まで緩和してもらうように申請します。
連絡先を入力して、上限緩和申請は完了です。後日状況を確認してみます。今回は1台のコンピュートノードでテストします。ロマン溢れる224vCPUのVMはそもそも起動させてもらえませんでしたね...
CPU上限の都合、さきほどのジョブを満たすノード数は上限緩和されるまで実行できません。ジョブをキャンセルします。
$ scancel 2
コンピュートノードは5分放置すると縮退して起動台数が0台に戻りました。
$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST p1* up infinite 10 idle~ blog-sample-cluster-compute-0-[0-9] p2 up infinite 10 idle~ blog-sample-cluster-compute-1-[0-9]
コンピューノード1台指定でジョブ再登録
仕切り直してコンピュートノードは1台だけ使ってジョブを登録します。
$ sbatch -p p2 -n 1 example.sh Submitted batch job 3
1台起動中です。
$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST p1* up infinite 10 idle~ blog-sample-cluster-compute-0-[0-9] p2 up infinite 1 alloc# blog-sample-cluster-compute-1-0 p2 up infinite 9 idle~ blog-sample-cluster-compute-1-[1-9]
ステータスがCF（CONFIGURING）で起動待ち状態です。
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
3 p2 example. ohmura_y CF 0:01 1 blog-sample-cluster-compute-1-0
ステータスがR（Running）で実行中です。
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
3 p2 example. ohmura_y R 0:02 1 blog-sample-cluster-compute-1-0
ホスト名を表示するだけのスクリプトなので一瞬でジョブが終わり、キューが空になりました。
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
実行結果確認
実行結果はLogin0インスタンスのホームディレクトリに保存されます。コンピュートノードのホスト名が記録されたファイルを確認できました。
$ pwd /home/ohmura_yasutaka_classmethod_jp $ ls example.sh slurm-3.out $ cat slurm-3.out blog-sample-cluster-compute-1-0
テストジョブを登録し、コンピューノードが起動し、コンピューノードでの実行結果を確認することができました。基本的な動作確認が取れ、チュートリアルとしては満足です。
削除
クラスター環境を削除して後片付けします。
残す理由もないのですべて削除します。
他に作成したものもないので、きれいさっぱりなくなりました。
おわりに
クラスターをデプロイする環境構築がWEB-UIで提供されており、とても簡単にクラスター構築できました、ほんと素晴らしい。私の考えではGoogle Cloudに詳しくなったからスパコン使おう！というよりも、オンプレでスパコン使っていてジョブ実行待ちなどの不満からクラウドHPCを使ってみたいなぁというモチベーションではじめてみたい方のほうが多いと思うんですよ。多くは研究者の方でみんながITに明るいわけではなく、そういったユーザが「クラウドわからん」と最初からつまづかないためにもとても親切な設計でした。
次回はコンピューノードに実行環境のセットアップなどを調べて、実践で使えるクラスターの構築方法を学んでいきます。
